…and the `: any` escapes on core slots are gone (#4127) (#4176)

Batch 2 of the #4127 gate. #4168 typed `getService` — easy, because every one
of its call sites already passed a `CoreServiceName`. `resolveService` is the
mixed one, and it is where the remaining `any` lived.

Overloads split it exactly where the evidence does. A `CoreServiceName`
resolves to the slot's contract; anything else keeps `any`:

- Core slots, however written. 17 call sites address a core slot with a bare
  literal (`'metadata'` x10, `'automation'` x3, `'auth'` x3, `'ai'`) rather
  than `CoreServiceName.enum.*` — the same slot addressed two ways. Both
  resolve to the contract now, with no edit to the call sites.
- Everything else — `protocol` (x22), `objectql` (x9), `mcp`,
  `kernel-resolver`, `security`, `scope-manager`. Real services with no
  `CoreServiceName` entry and no written contract. They keep `any` rather than
  being given a shape here that nothing verifies: that `any` is where the
  ledger honestly ends, and writing those contracts is its own change.

The typing was being erased at three call sites, and that is the actual
finding. `const x: any = await deps.resolveService('auth', ...)` defeats all of
this — the annotation wins and #4168's work does nothing there. Sweeping for
the pattern found three on core slots:

`/mcp` x2 — two more undeclared methods. The domain calls
`authService?.getMcpResourceUrl?.()` and `?.getMcpResourceMetadataUrl?.()`.
AuthManager implements both (plugin-auth uses them internally); IAuthService
declared neither. Call site and implementation agree, the contract is the thing
nobody wrote.

The `: any` + optional-chaining combination made this WORSE than the earlier
gaps, not better: invisible to the type system AND accidentally safe. An absent
method returns `undefined`, so the skill route silently fell back to deriving an
MCP URL from the request host — a real disagreement between the auth service's
canonical value and the derived one would have looked like normal operation. The
whole point of `getMcpResourceUrl` is that it comes off the auth `basePath` so
the two CANNOT disagree about the API prefix; the route's own comment says "the
auth service owns the canonical value".

Both declared optional: an auth provider without MCP/OAuth support fills the
slot legitimately, and `getMcpResourceMetadataUrl` returning `null` (OAuth track
off) stays distinct from the method being absent.

`/packages` x1 — `const metadata: any = await deps.getService(...metadata)`,
feeding `new SeedLoaderService(ql, metadata, ...)`. Annotation dropped; it
typechecks against IMetadataService now. Its neighbours `protocol` and `ql` keep
their `any` for the honest reason above.

No other core-slot lookup is annotated away — the sweep is exhaustive over
domains/*.ts. `api-surface.json` is unchanged: the two additions are interface
MEMBERS, not new exports.

Refs #4127


Claude-Session: https://claude.ai/code/session_015T5CeitwV1jXLvsL1A84tw

Co-authored-by: Claude <noreply@anthropic.com>

…Name` (#4127) (#4202)

Batch 3 of the #4127 gate, after #4168 (`getService`) and #4176
(`resolveService`).

Three slots — `security`, `shareLinks`, `objectql` — each had a written
contract, a provider registering them, and call sites already inside the
contract. The only missing link was that the slot name was not a
`CoreServiceName` member, so nothing could connect them and all three sat
behind `as any`.

The ledger extends past the enum rather than the enum growing. The two answer
different questions, and conflating them is what left these untyped:
`CoreServiceName` answers "what happens at boot when this slot is empty?" — it
sits beside `ServiceCriticality` and drives startup orchestration and
discovery, so adding a member changes runtime behaviour and is effectively
permanent. The ledger answers "what shape occupies this slot?" — pure type
information. These three need only the second, so `ServiceSlotContracts extends
CoreServiceContracts` adds them there and `resolveService` keys on `keyof
ServiceSlotContracts`. Zero runtime effect. If one is later promoted to a
genuine core service, its entry moves up and nothing else changes; a test
asserts these keys are NOT enum members, so that migration cannot happen
silently.

Evidence before an entry, as always: `plugin-security` registers `security` and
`ISecurityService`'s own doc names that registration; `plugin-sharing`
registers `ShareLinkService`, which declares `implements IShareLinkService`;
and `objectql` is an ALIAS of `data` — `packages/objectql`'s plugin registers
the same instance under both names two lines apart, so one object was resolving
as `IDataEngine` through one name and `any` through the other. `protocol` (22
call sites) and `mcp` have no written contract and stay unmapped.

Turning it on found four things, all on the `/security` admin surface:

1. Request input reached the security service unvalidated. `?status=` was
   `String(query.status)` — any string — handed to a method whose contract
   declares exactly three values, and from there into the query's `where`
   clause. Not an injection (the `where` is structured, never interpolated),
   but `?status=garbage` matched no row and returned an empty list, which reads
   as "there are no suggestions" rather than "that is not a status". Now a 400.

2. A test pinned that bug as expected behaviour. The existing case asserted
   `status: 'open'` — not one of the three declared values — reached the
   service and returned 200. It proved the delegate carried A FILTER and
   nothing about that filter being a status. Same shape as batch 1's
   `auth.handler` mocks: coverage in appearance, a wrong contract in substance.

3. and 4. Two writes could not prove they had a caller.
   `confirmAudienceBindingSuggestion`/`dismissAudienceBindingSuggestion`
   declare `callerContext: SecurityContext` non-optionally — deliberately,
   since the read beside them declares it optional — and the domain passed a
   possibly-`undefined` execution context.

   This was NOT a live hole, and the distinction matters: with no execution
   context `shouldDenyAnonymous` already denied, because it sees no
   `userId`/`isSystem` and its allowlist arm needs a non-empty `path` this seam
   never passes, so it fell through to `return true`. What it never did was
   narrow `ec` itself — it only read `ec?.userId`. Checking `ec` directly is
   behaviour-preserving and makes the invariant legible to the compiler and the
   next reader.

The `?status=` rejection is the one BEHAVIOUR CHANGE: an unknown status was a
silent empty list and is now a 400 naming the accepted values. The accepted set
is a `Record` keyed on the contract type, so adding a status to the contract
leaves a key missing and renaming one leaves a key excess — either fails to
compile, where a plain array would have drifted silently. Documented on the
permission-sets page, where the endpoint is described.

Refs #4127

… which found the project-membership gate not gating (#4127) (#4214)

Batch 4 of the #4127 gate. #4168/#4176/#4202 made a slot lookup return the
slot's contract. Nothing protected that: an `any` annotation on the RESULT
switches the checking back off for that call site, silently, with no test
failing and no visual difference from code that has it. Three such sites already
existed and were found by grep — the same unrepeatable sweep this work replaced.

The rule bans `: any` / `as any` on a `resolveService` / `getService` /
`getRequestKernelService` result. Slots with no written contract (`protocol`,
`mcp`, `kernel-resolver`, `scope-manager`) are exempted BY NAME, CENTRALLY, in
eslint.config.mjs — not by inline disables, because `pnpm lint` runs
`--no-inline-config` and ignores those on purpose. The effect is the one worth
having: a deliberate gap is a reviewed line in one file, a careless one is a
build failure, and they stop looking identical in the code.

ITS FIRST RUN FOUND A LIVE FAIL-OPEN. `enforceProjectMembership` read the
session as `authService?.api?.getSession?.(...)` with no `getApi()` fallback —
the only one of the codebase's three `.api` readers without it. `plugin-auth`
registers `AuthManager`, which has NO `.api` member at all. So the read yielded
`undefined`, `userId` stayed unset, and the function returned at its "anonymous
— upstream auth will decide" line BEFORE ever querying `sys_environment_member`.
A signed-in non-member passed the gate, on every deployment with project scoping
on — which is where the flag defaults to true. Anonymous callers were still
denied elsewhere (#2567/#3963), so this was specifically the signed-in
non-member case.

The existing test for that gate mocked auth as `{ api: { getSession } }` — the
legacy shape the shipped provider does not have — so it was green throughout.
That is the FOURTH test in this work line found encoding a contract nobody
implements, after batch 1's three `auth.handler` mocks and batch 3's
`status: 'open'`. The new test uses the `getApi()` shape and fails against the
pre-fix code.

Also found by the rule, all the same #4127 shape (implemented, called,
undeclared) and all now declared: IAuthService gains `api`, `getApi`,
`isAuthGateActive` and `verifyMcpAccessToken`; IMetadataService gains `load` and
`loadDiagnosed`. `getApi`'s return type is the EVIDENCED SUBSET —
`getSession({headers})` and the three fields callers read — not a
re-declaration of better-auth's handle, which belongs to that library.

And the pattern's real root: the lookup facade returning `any` was re-declared
in THREE places. Batches 1-3 typed `DomainHandlerDeps` and left
`ActionExecutionDeps` and resolve-execution-context's `ResolveOptions` still
saying `any` — so the copy that stayed untyped was the way around all the
others, and it is where the auth reads lived. All three are typed now.

Completing the interface: `getRequestKernelService` gets the same overload split
(its one caller resolves the same `objectql` slot the `resolveService` fallback
beside it does, so the two arms of one expression had different types), and
share-links' `getEngine` loses a `Promise<any>` return annotation — a THIRD
erasure syntax after `: any` and `as any`, and one this AST rule cannot see.
That residual is documented in the config.

`getObjectQL` STAYS `any`, deliberately, with the reason recorded: it exists to
reach ObjectQL's surface beyond IDataEngine (`registry`, `executeAction`), which
has no contract. Typing it IDataEngine would be the comfortable-looking lie.

The auth and metadata contract doc pages are brought back in step with the
interfaces — the auth page still called itself "intentionally minimal" while
missing six members, two of them from batch 2.

Refs #4127